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Foreword 

This Technical Specification has been produced by Ericsson, Siemens, Motorola and Nokia. 



Introduction 

This technical specification describes an architecture that fulfils the user requirements described in reference [1], 

The basic architecture is described in clause 4. . 

The functional entities of the architecture are described in clause 5. 

The interfaces of the architecture are described in clause 6. 

General system concepts, that have architectural implications, are described in clause 7. 

An overview of the high level procedures, for informational purposes, is described in clause 8. 
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1 Scope 

This document describes the functional entities, interfaces, system concepts and high-level procedures of the Push-to- 
Talk over Cellular (PoC) service. 

The PoC service is characterized by a half duplex form of communication whereby one user will communicate with 
other users by pressing a button (or by performing equivalent action) on an PoC enabled User Equipment (UE). 

This specification is part of PoC release 1.0. 

2 References 

The following documents contain provisions, which through reference in this text constitute provisions of the 
present document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a PoC document, a 
non-specific reference implicitly refers to the latest version of that document in the same Release as the 
present document. 



[I] Push-to-Talk over Cellular User Requirements; PoC Release 1 .0 
[2] PoC Signaling Flows; PoC Release 1 .0 

[3] PoC User Plane; Transport Protocols; PoC Release 1 .0 

[4] PoC User Plane; (E)GPRS Specification; PoC Release 1 .0 

[5] PoC List Management and Do-Not-Disturb; PoC Release 1 .0 

[6] 3GPP TS 23.228 "Technical Specification Group Services and System Aspects; IP Multimedia 
Subsystem (IMS); Stage 2 (Release 6)" 

[7] 3GPP TS 24.008 "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3" 

[8] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 
5)" 

[9] IETF RFC 1 332 "The PPP Internet Protocol Control Protocol (IPCP)" 

[10] IETF RFC 1877 "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" 

[I I] IETF RFC 1 889 "RTP: A Transport Protocol for Real-Time Applications" 
[12] IETF RFC 2616: "Hypertext Transfer Protocol HTTP/1. 1" 

[13] IETF RFC 3261 : "SIP: Session Initiation Protocol" 

[14] IETF RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers" 

[ 1 5] IETF RFC 3320: "Signaling Compression (SigComp)" 

[ 1 6] IETF RFC 332 1 : "Signaling Compression (SigComp) - Extended Operations" 

[17] IETF RFC 3485: "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) 
Static Dictionary for Signaling Compression (SigComp)" 

[18] IETF RFC 3486: "Compressing the Session Initiation Protocol (SIP)" 
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[19] . IETF < draft-ietf-sip-calleiprefs-09.txt> (expire December 29, 2003): "Caller Preferences for the 

Session Initiation Protocol (SIP)" 

[20] IETF <draft-ietf-simple-presence-10.rxt> (expires July 2003): "A Presence Event Package for the 

Session Initiation Protocol (SEP)" 

[2 1 ] ITU-T Recommendation E. 1 64 : "The international public telecommunication numbering plan" 

[22] IETF RFC 2486: 4 The Network Access identifier". 

[23] IETF RFC 2806 "URLs for Telephone Calls" 



3 Definitions and abbreviations 



3.1 Definitions 

For the purposes of the PoC specifications, the following terms and definitions apply. 

Access control: Each PoC user can define rules that describe who is allowed to contact him/her using the PoC service. 
The PoC Server implements the access control policy according to these defined rules. 

Access list: Each PoC user has two access lists: a user accept list and user reject list. Access lists are used for 
controlling whether the PoC server is allowed or not to send talk session requests to the user when requested by other 
user. 

Ad-hoc instant group talk: A feature providing a user to ad-hoc establishes a PoC session with other PoC users. 

Chat group: A persistent group created for chat group talk. Each group member joins the talk session individually. 

Chat group talk: A feature providing users with the capability .to join a pre-defined chat group. The chat group may be 
open or restricted. 

Chat talk session: A talk session established by a chat group talk. 

Contact list: A list available to the end user containing the addresses of other users or groups. 

Contact: A contact is an identity of a user, or a group. A contact includes the SIP URI or a TEL URJ of the entity, type 
of the entity (user or group) and optionally the display name. 

Floor control: A control mechanism that arbitrates requests, from the UEs, for the right to speak. 
Group Talk: An instant group talk, ad-hoc instant group talk or chat group talk. 

Group: Group is predefined set of users together with its attributes. The group is used for easy session establishment 
and/or for defining session access policy. Each group is identified by its SIP URI. . 

Instant group: A persistent group created for instant group talk. The users PoC server invites all the other group 
members to a talk session. 

Instant group talk: A feature providing a user to establish a PoC session with other members in a pre-defined instant 
group. The instant group is always a restricted group. 

Instant personal Alert: A feature providing a user with the capability to send a callback request to another user. 
Instant persona) talk: A feature to establish a PoC session with another user. 

Instant talk session: A talk session established by instant personal talk, ad-hoc group talk or instant group talk. 

Invited user: This is the PoC user who has been invited to a talk session. 

Inviting user: This is the PoC user inviting other PoC user(s) to the to a talk session. 
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maxptime: The maximum amount of media which can be encapsulated in a RTP payload packet, expressed as time in 
milliseconds. The rime is calculated as the sum of the time the media present in the packet represents. The time should 
be a multiple of the frame size. In PoC the allowed values are N*20; where N>0 and N<21. 

media capabilities list: In this list, the PoC Server shall store the downlink media capabilities of all UEs that are active 
in sessions served by the PoC Server. 

media capabilities: A set of parameters that should describe the performance of the PoC user equipment (UE), the 
speech coder used and the performance of the radio bearer that carries the PoC service (the quality of service parameters 
agreed upon etc). 

media parameters: The PoC Server uses the media capabilities list to determine the settings the user equipments 
should use in the talk session. The information transmitted from the PoC Server to the UE in order to alter the settings 
of the UE, is in this document referred to as media parameters. Media parameters are transmitted by SIP/SDP messages. 

mode-set: Restricts the active codec mode set to a subset of all modes. Possible values are a comma separated list of 
modes from the set: 0,,..,7. If the decoder specifies such mode set, the encoder MUST abide by the request and MUST 
NOT use modes outside of the subset. If not present, all codec modes are allowed for the session. 

Open group: A group that can be joined by any user. 

Participant: A PoC user in talk session. 

ptime: Number of frames per RTP-packet the UE needs to be able to receive the media stream on its downlink. Prime is 
given as the length of time in milliseconds represented by the media that needs to be in a RTP packet. 

Restricted group: A group that can be joined only by predefined user(s). 

Session: A session is considered as an exchange of data between associations of participants. 

Talk session: This is an established connection between PoC users where the users can communicate one at a time in a 
half duplex manner. 

talk spurt: A part of the speech signal that starts with a speech onset and ends when the speech coder goes down in 
DTX-mode. Hence a talk burst can consists of several talk spurts. 

Talk-burst: The media recording, transport and playback that occur from when the user has the floor. 

User: A human using the described features through a terminal device. 

User accept list: User accept list is a list of items each identified by its SIP URL 

User equipment: User equipment is a hardware device (e.g. phone) with Push-to-Talk software used by users. 
User reject list: User reject list is a list of items each identified by its SIP URL 



3.2 



Abbreviations 



For the purposes of the PoC specifications, the following abbreviations apply: 



AMR 

DNS 

DTD 

FQDN 

FFS 



GGSN 

GLMS 

HTTP 

IMS 

IPCP 

ISC 

MD5 

N/A 



GERAN 



Adaptive Multi Rate 
Domain Name System 
Document Type Definition 
Fully Qualified Domain Name 
For Further Study 

GSM/EDGE Radio Access Network 
Gateway GPRS Support Node 
Group and List Management Server 
Hypertext Transfer Protocol 
IP multimedia subsystem 
Internet Protocol Control Protocol 
IMS service control interface 
Message Digest no. 5 
Not Applicable 
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NA1 Network Access Identifier 

NAPTR Naming Authority Pointer 

P-CSCF Proxy-CSCF 

PCO Protocol Configuration Options 

PDP Packet Data Protocol 

PoC PTT over Cellular 

PTT Push to Talk 

RTCP RTP Control Protocol 

RTP Real-time Transport. Protocol 

SIP Session Initiation Protocol 

SRV DNS resource record for the location of services 

UCS Universal Character Set 

UE User Equipment 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

UTF-8 UCS Transformation Format 8 

UTRAN Universal Terrestrial Radio Access Network. 

XML Extensible Mark-up Language 

3.3 Requirement vocabulary 

. Shall Indicates a mandatory requirement. 

Should Indicates a recommendation. 

May Indicates an optional requirement. 
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Architecture 



The PoC functional architecture is outlined in Figure 1 

Im 



UE 



w 
o 
u 



Is 




Dc 



"1- 



It 



(talk) 



If 



I 
o 
CO 

o 



Q ut Q ^ Scope 
Represents functional entities only 



Figure 1 : PoC architecture 

NOTE: The access in the PoC architecture includes both the radio access as well as the other nodes required to 
gain IP connectivity (e.g. GSNs). 

PoC shall be based on IMS as specified in 3GPP TS 23.228 [6] and TS 24.229 [7], with exceptions regarding to: 

IPv4 only is supported. . . 

The IMS-enabled PoC service may be offered through mobile networks different from that specified in 3GPP 
release 5. This implies modified interfaces to the network environment for in the areas of charging and QoS 
support, and a modified authentication mechanism and modifications in the SIP signaling. 

In this release of the PoC specification only interfaces between the network and the UE will be specified! Therefore Im, 
Is, and It are the only interfaces to be specified in this release of the PoC specification. 

Nevertheless all core internal interfaces as depicted in the architectural picture above shall be based on IMS. All 
relevant core internal interfaces (including, but not limited to ISC) will be specified in subsequent releases of the PoC 
specifications. 

NOTE: When PoC service is offered through a mobile network according to 3GPP release 5, and subsequent IMS 
releases, IMS signaling as defined by 3GPP shall be complied to. 
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5 Description of functional entities 

5.1 User Equipment (UE) 

The UE is the terminal equipment containing the PoC application client software. 

5.2 IMS Core 

The IMS core includes a number of SIP proxies and SIP registrars according to [6] and [13]. The first point of contact 
for UE is one of the proxies in the IMS core that is configured on the UE as the outbound proxy. In the IMS 
architecture, the outbound proxy is known as the P-CSCF. The IMS Core performs the following functions: 

Routes the SIP signaling between the UE and the PoC Server; 

Terminates the SIP compression from the terminal; 

Authentication and authorization; 

Maintains the registration state and the SIP session state; 

Reporting to the charging system. 

The UE shall send all its SIP messages to the IP address of the outbound proxy after resolving the SEP URI of the 
outbound proxy to an IP address. 

5.3 Group and List Management Server (GLMS) 

PoC users use the GLMS to manage groups, contact lists and access lists. 

A contact list is a kind of address book that may be used by PoC users to establish an instant talk session with other PoC 
users or PoC Groups. A user may have one or several contact lists including identities of other PoC users or PoC 
Groups. Contact list management includes operations to allow the UE to store and retrieve the contact lists located in 
the GLMS. 

The end users can define PoC groups. The end user may select one group from the list to initiate an instant group talk 
session or a chat group talk session depending on the type of the group. 

An access list is used by the end user as a means of controlling who is allowed to initiate instant talk sessions to the end 
user. An access list contains end user defined identities of other PoC end users or groups. The end user may have one 
blocked identities list and one granted identities list. 

5.4 PoC Server 

The PoC Server contains the PoC service. The PoC Server performs the following functions: 
End-point for SIP signaling; 
- End-point for RTP and RTCP signaling 
Provides SIP session handling 
Provides policy control for access to groups 
Provides group session handling. 
Provides access control 
Provides do not disturb functionality. 
Provides the floor control functionality; 
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Provides the Talker identification 
Provides the Participants information 
Provides the Quality feedback 
Provides the Charging reports 
Provides the Media distribution. 

5.5 Presence Server 

The presence server is not standardized in PoC release 1.0. 

The Presence Server shall manage presence information that is uploaded by the Presence User/Network/External agents, 
and is responsible for combining the presence-related information for a certain presenrity from the information it 
receives from multiple sources into a single presence document 

6 Description of the interfaces 

6.1 Interface Is: UE - IMS Core 

The Is interface supports the communication between the UE and the IMS' Core.. This communicarion includes the SIP 
procedures defined in [2] to support the PoC features defined in [1]. 

The protocol for the Is interface is SIP (as defined by [13], other relevant IETF RFCs and necessary additions from [8]). 
The SIP signaling across this interface is subject to SIP signaling compression defined in [2], The Is signaling shall be 
transported on UDP. 

NOTE1 : TCP transport for the Is interfaces is not supported in PoC release 1.0. 

NOTE2: Presence service interactions between the UE and the IMS core will be specified in a future PoC release. 

6.2 Interface If: IMS Core - PoC Server 

The protocols over If interface support the communication between the IMS core and the PoC Server for session 
control. 

NOTE: The If interface is not specified in the PoC release 1.0. 

6.3 Interface It: UE - PoC Server 

The protocols over It interface support the transport of talk bursts, floor control and link quality messages between the 
UE and the PoC Server. 

The protocols for the It interface are RTP and RTCP [11] with details described in [3]. 

6.4 Interface Im: UE - GLMS 

The protocols over Im interface support the communication between the UE and the Group and List Management 
Server (GLMS) for the purpose of managing the groups, contact lists and access lists and Do-not-Disturb indication. 
The HTTP/XML protocols shall be used as defined in [5]. 

The group and list management operations are detailed in [5]. 
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6.5 Interface Ik: PoC Server -GLMS 

The protocols over Ik interface support the communication between the PoC Server and the GLMS; enabling the PoC 
Server to retrieve the groups and access lists from the GLMS. 

NOTE: The Ik interface is not specified in the PoC release 1.0. 

6.6 Interface Ips: IMS core - Presence Server 

The protocols over Ips interface enable the uploading of the registration status from the IMS core to the Presence Server 
and the dissemination of the presence information between the presence server and the UE. 

NOTE: The Ips interface is not specified in the PoC release 1 .0. 

67 Interface I pi: Presence Server - GLMS 

The protocol over Ipl interface enables the uploading of the Do-not-Disturb status and the granted/blocked access lists 
from the GLMS to the Presence Server. 

NOTE: The Ipl interface is not specified in the PoC release 1 .0. 

7 System concepts 
7.1 Identification 

7.1 .1 Address of record (a.k.a. public user identity) 

The PoC operator shall assign, to each user, an address-of-record (also known as public user identity) in the form of a 
SIP URJ where the user part of the URI uniquely identifies the user, and this could be an alphanumeric string. The host 
part of the URI uniquely identifies a domain owned by the operator. The address-of-record shall comply with the 
specification of a SIP URI in [13]. 

The address-of-record is used for PoC only or for PoC and other SIP based services. 
Examples of address-of-records are: 

sip:joe.doe@operator.net; 

sip:buss2. city@operator.net; 

sip:buss2.city@poc.operator.net. 

7.1.2 Private user identity 

The network operator shall assign to the user a private user identity for authentication purposes. The private user 
identity shall be hidden from the other users and cannot be used for addressing. 

The private user identity shall take the form of an NAI, and shall have the form usemame@realm as specified in section 
3 of RFC 2486 [22]. It is configured in the UE. 

7.1.3 Group identities 

The group identity used on the Is interface (between the UE and IMS core) for group talk, shall be generated by the 
GLMS and shall comply with the specification of a SIP URI in [13]. The GLMS shall generate the group identity 
according to reference [5]. 
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7.1 A Contact list identities 

A contact list identity uses the generic address format defined in [13] and shall be used to address the contact lists in the 
GLMS. The GLMS shall generate a URI for each contact list as specified in reference [5]. 

7.2 Addressing 

7.2.1 IP addresses 

Each entity in the PoC system shall be assigned one or more IP addresses belonging to public or private IP realms. 
IPv4 is mandatory. • 

7.2.2 Phone numbers 

•4 

A PoC user may address another user by a phone number. The UE shall send the phone number to the IMS core in a 
TEL URL [23]. 

The phone number may use the international E. 164 [21] format (prefixed with a sign), or a local format using a local 
dialing plan and prefix. The IMS core shall interpret the phone number with a leading to be an E. 164 number. 

Addressing by TEL URL for a PoC session requires that the PoC Server can resolve the TEL URL to a SIP URI, for 
instance by using DNS/ENUM or other local data base. A phone number in a local format shall be converted to the 
E. 1 64 format before DNS/ENUM is used. 

7.2.3 SIP URI 

A PoC user may address another user by a SIP URI. 

7.3 Routing principles 

7.3.1 Registration 

The PoC user shall register itself with the IMS core before using the PoC service. 

The UE binds the public user identity and the UE IP address and port at registration with the IMS core. The UE shall 
include the public user identity as the address-of-record in the To header and the IP address as the host part of the SIP 
URI in the Contact header. 

The UE shall include the media feature tag [19] indicating the PoC service in the Contact header. The IMS core may 
use this information for routing. 

7.3.2 Session establishment 

The INVITE request on the Is interface shall contain the Accept-Contact header [19] with a media feature tag indicating 
the PoC service. The IMS core shall be able to identify the request as PoC communication by inspecting the Accept- 
Contact header. 

The Request-URJ of the INVITE shall contain either the pre-configured ad-hoc identity (for instant personal talk and 
ad-hoc instant group) or a group identity (for instant group talk or chat group talk). The pre-configured ad-hoc identity 
is assigned according to reference [2] 

Early session establishment is used for having session available for quick connection establishment with REFER. Early 
session establishment's INVITE does not have any referred party field and can be differentiated from this against other 
INVITEs. 

The transient group identity is generated by the PoC server and distributed to the UE in the contact header. 
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From the initiating UE, the public user identity of the inviting user shall be included in the From header. On the 
signaling towards the invited user, the From header includes either the public user identity (instant personal talk, ad-hoc 
instant group) or the group identity (instant group talk or being added to a chat group). 

7.3.3 User location 

Users shall use the Address of record or phone number (as described in 7.2.2 and 7.2.3) of other users to address them. 
The IMS core is responsible for routing the requests to the users according to the bindings established through 
registrations. 

7.4 Security 

7.4.1 Threats 

There are a number of SIP threats identified in [13]. The main problem is that it is simple to steal and use another 
user's identity unless the identity is properly authenticated. The main threats by unauthorized use of an identity are 
according to [13]: 

Registration Hijacking; ■ r 

Impersonating a Server; 

Tearing Down Sessions. 

Another threat is fraud where a malicious user steals another user's identity to talk and let the other user pay for that. 

7.4.2 Countermeasures 

The best and simplest countermeasure to the threats above is to.properly authenticate the SIP requests from a user. The 
Digest procedure defined in [13] shall be supported between the UE and IMS core for authenticating the user. The UE 
shall include any stored credentials in all relevant SIP requests to avoid unnecessary signaling. With the digest 
procedure, the IMS core should challenge the user if a relevant SIP request lacks credentials or the credentials are 
invalid. The details for the authentication procedure are defined in [2]. 

A user shall be authenticated with the GLMS by using the procedures defined in [5]. 

In the case of HTTP digest, then the same digest password should be used by the UE when communicating with GLMS 
or IMS core. The UE should not prompt the user for a digest password if the password is configured in the UE. Any 
configured password should be protected, for example, by encryption. 
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7.5 Floor control 

Floor control includes the following actions: 

- floor request; 

The action provides the capability for a participant in a talk session to ask for permission to talk. 

- floor release; 

The action taken be a granted user to release their permission to talk. 

- floor grant; 

An action from the network to inform requesting participant that the floor has been granted. 

- floor idle indication; 

An action from the network to inform participants that the floor is idle. 

- floor deny; 

An action from the network to inform the requesting participant that the floor request is denied. 

- floor taken; 

An action from the network to inform all participants that the floor has been granted to the indicated user. 

- floor revoke; 

The action from the network to remove the permission to talk from a user who has previously been granted 
the floor 

- talk burst quality feedback. 

reports the amount of media received by the PoC server or by the UE. 

- RTCPBYE; 

indicates that the sending party wants to terminate the ongoing media session in current communication 
context, without changing the SIP-session state 

The talker arbitration performed through the use of RTCP. 

The talker identification distributed through the use ofRTCP 

The talk burst quality feedback is distributed through the use ofRTCP RR and SR 

Floor control is described in detail in [3]. 

7.6 Codecs 

PoC has the AMR speech codec as the mandatory speech codec for the GSM, GERAN and UTRAN radio access 
networks. The details describing how AMR is used in PoC is found in [3]. The codec rate depends heavily on the radio 
cell configuration and the latency for GSM/GERAN/UTRAN. 

7.7 Signaling compression 

The UE and the IMS core shall compress the SIP signaling according to [15], [16], [17] and [18] to reduce the 
transmission delays. Details how this is done are described in [2J. 

The grouping of messages (compartments) starts at registration and ends at de-registration. 

A static SIP dictionary [17] shall be stored locally in the UE and the IMS core. A user specific dictionary [16] may be 
uploaded by the UE to the IMS core and stored there as part of the registration procedure. The user specific dictionary is 
used to increase the compression rate in particular for the initial SIP messages. The SEP URJ shall include the signaling 
compression indication as described in [18]. 
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7.8 User plane adaptation 

The media throughput is affected by the conditions on the radio access link. The talk burst (user plane) bit rate shall be 
reduced in case the talk burst bit rate is higher than the available end-to-end bit rate. The available bit rate is indicated 
with RTCP. The talk bursts bit rate can be reduced if necessary by re-negotiation with SIP. 

7.9 Charging 

The charging models that should be supported are described in [1], The PoC architecture shall be able to support the 
following oflline charging mechanisms to support these charging models: 

The IMS core network nodes and the P6C Server shall be able to report to the charging system upon reception 
of various SIP methods since charging relevant information is contained in these messages; 

The PoC Server shall be able to report a talk burst end event to the charging system. The message sent to the 
charging system for the talk burst should include any relevant SIP and SDP parameters for the ongoing session, 
the numbers of bytes sent, the number of packets sent and the duration of the talk burst. 

The PoC Server shall be able to report to the charging system the number of packets and bytes a UE has 
received in a talk burst. The UE reports these parameters in a receiver report message; 

The delivery of the receiver reports and the talk burst end are not reliable. The PoC Server shall be able to 
report to the charging system after a timer expiry in case both of these messages are lost. 

The receiver report cannot be trusted. In case there is a long-term difference between the number of bytes sent from 
PoC server and the information received in the receiver report, this is an indication of fraud. 

The bearer charging is also used in parallel. The correlation between the bearer charging and service charging shall be 
done in the charging system. 

A deployed network may implement all, some or none of the charging models described in this sub-clause. 

7.10 Roaming 

The PoC user may roam in a visited network. GPRS roaming can then be used which means that a home GGSN and the 
home IMS core are always used. 

7.11 Presence 

For further study 

7.12 Do-not-Disturb 

The user can enable the Do-not-Disturb (DnD) feature in the UE. The network or the UE with the enabled DnD will 
then reject all incoming sessions. The inviting user does then recognize the response as a busy indication. 

The user updates the DnD setting in GLMS. This is described in detail in [5]. 



8 High level procedures 

The clause gives examples on PoC signaling procedures. Details are described in the Signaling flows [2] 
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8.1 PDP Contexts 

A PDP Context with the interactive traffic class with the highest priority should be used for the SIP, DNS and 
HTTP/XML signaling. The signaling PDP Context is a Primary PDP Context that shall be activated before the SIP 
registration. This PDP Context should be activated at least as long as the SIP registration lasts. 

In case, the radio access network does not support the streaming class or the streaming class usage is subject to local 
policy, a PDP Context with the- interactive traffic class with the highest priority should be used for media. The Primary 
PDP Context may be used for the media. As an alternative a Secondary PDP Context with the interactive traffic class 
may be used for the media instead of the Primary PDP Context. 

In case the radio access network supports the streaming traffic class and the local policy allows its usage PDP Context 
with the streaming traffic class should be used for the media to provide high quality voice. The PDP Context for the 
streaming traffic class is a Secondary PDP Context that is activated in parallel with the establishment of Instant 
Personal Talk or Group Talk. 

8.2 DNS name server discovery 

The UE obtains IP addresses of the DNS name servers as part of the PDP context activation. 

The IPv4 addresses for the DNS name servers (primary and secondary) are included in the Protocol Configuration 
Options (PCO) [7]. The PCO format uses the IPCP [9] field that is defined in [10]. 

8.3 DNS procedures 

8.3.1 SIP URI resolution 

The address of the outbound proxy in the IMS core is configured into the UE in the form of a SIP URI. The URI should 
include the transport protocol (UDP) and the port number the proxy is listening to and an indication that compression 
should be used (comp=sigcomp). 

In order to contact the outbound proxy, the UE performs a DNS query on the host part of the SIP URI of the proxy 
following the rules described in [14]. Note, however, that if the host part is an IP address rather than an FQDN the UE 
does not need to consult the DNS. 

Note that if the SEP URI of the outbound proxy that is configured in the UE follows the format recommended above 
(transport protocol and port number explicitly given), following the procedures in [14], the UE performs an A query. If 
the recommended format is not followed, the UE might need to perform NAPTR or/and SRV queries. 

Example of the recommended format for the SIP URI configured in the UE pointing to the outbound proxy: 

sip:outbound-proxy.my-operator.com:5060;transport=udp;comp=sigcomp 

8.3.2 HTTP URL resolution 

The UE resolves a HTTP URL according to [12] or to best current practice. 

NOTE: The Im request is sent to a proxy identified by a configured address in case a WAP or HTTP proxy is 
used. In that case the proxy resolves the HTTP URL according to [12] or to best current practice. 

8.4 Early Session dialog establishment 

The early session provides the instant personal communication forehd-user. The early session enables the UE to 
communicate the IP addresses and ports, which are used for sending the RTP/RTCP packets. 

The early session is used for service negotiation purposes between the end user and his/her home PoC application 
server. 
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The early session is established for service negotiation purposes right after the initial registration, or the UE may request 
the early session for instant personal communication at any later time point (e.g. when the end-user activates the instant 
personal communication from the UE). 



8.5 



Instant Personal Talk 



In an Instant Personal Talk, user A establishes an PoC session with user B (via the PoC Server). Connection setup may 
be done either with early session procedure and SIP REFER or with SIP INVITE. 

In early session case the User A and User B establish early sessions after registration towards their PoC servers and 
during the connection establishment phase the session is established with using SIP REFER. If user A's terminal 
supports early session and auto answer is defined for user B Fieure 2 's signalling sequence is applied. NOTIFY 
message is sent to user A after the first talk burst. 



User A 



Button down 



Ready 



(1) REFER 



. Floor granted _ 
(3) 202 Accepted 



PoC Server 



User B 



Floor taken 



Figure 2: Early session and auto answer procedure 



User A sends a SIP INVITE to the PoC Server including user B f s address in a body whose type is 
application/vnd.siemensericssonmotorola.PoC. When the PoC Server receives this INVITE, it performs an authorization 
decision based on the Do-not-Disturb setting in the GMLS. If the invitation is authorized, the PoC Server inspects the 
application/vnd.siemensericssonmotorola.PoC body to discover user B's address and, depending on the network 
configuration, it initiates early media procedures (optional) or late media procedures. 

If the PoC Server is configured to use the optional early media procedures, it will, as shown in Fi gure 3. answer the 
INVITE with a 202 (Accepted) response. This response, together with the "floor grant" message from the talker 
arbitration process, informs user A that user B has not been reached yet, but that the PoC Server is already prepared to 
receive media. The PoC Server will buffer all the media received from user A until it can be delivered to user B. When 
user B is finally contacted, the PoC Server informs user A about this using a NOTIFY request. 
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Figure 3: Early media and auto answer procedure 

If the PoC Server is configured to use the late media procedures, it will, as shown in Figure 3 simply relay the responses 
received from user B to user A. 



User A 

Button down 



Ready 



(1) INVITE 



(4)180 Ringing 



-r- (6) 200 OK 
(7)ACK 



. Floor granted 



PoC Server 



(2) INVITE 



(3) 180 Ringing 
(5) 200 OK 



Floor taken 
- (8)ACK 



User B 



Figure 4: Late Media and Manual answer procedure 

Once the session has been established, either } .user A or user B can terminate it at any time. In case of inactivity, the PoC 
Server can also terminate the session (no talk bursts within a configured time period). 

8.6 Ad-hoc Instant Group Talk 

In an Ad-hoc Instant Group Talk, user A establishes a PoC session with a set of users (via the PoC Server). 

For the early media procedures and the late media procedures are similar to those described in figures 3 and 4. The 
difference is that in an Ad-hoc Instant Group Talk, the application/vnd-poc .refer-to body of the initial INVITE from 
user A will contain more than one addres. Therefore, the PoC Server will send more than one INVITEs as a result. 
However, the fact that there are multiple INVITEs triggered by user A's initial INVITE is hidden from user A. The PoC 
Server will send to user A a single NOTIFY in the early media case and a single 180 (Ringing) response in the manual 
answer case. When using the optional early media procedures for ad-hoc groups, the PoC server begins to play the 
media when the first invited party accepts. 

For the early session case procedures are similar to those described in figure 3. The difference is that in the REFER 
from user A will contain more than one address. PoC server will initiate several session setups towards B parties. The 
setup will be done with auto or manual answering mode depending on the Bs configuration. 

Note that, according to the description above, an instant personal talk (sub-clause 8.4) is only a special case of an Ad- 
hoc Instant Group Talk. Therefore, in all cases the user portion of the Request-URI of the initial INVITE will be set to 
the pre-configured ad-hoc string. The PoC Server will return in the Contact header of the final response for the INVITE 
a unique identifier for the Instant Personal or Instant Group Talk. 



8.7 Instant Group Talk 



The signaling messages exchanged to establish an Instant Group Talk are the same as for an Ad-hoc Instant Group Talk. 
The only difference is that the Instant Group Talk has an already existing identifier while the identifier for the Ad-hoc 
Instant Group Talk was created at establishment time. Therefore, the Request-URI of the initial INVITE will be set to 
the identifier of the Instant Group Talk, as opposed to the Ad-hoc case where the "ad-hoc" convention for the user part 
is used. 



8.8 Chat Group Talk 

In a Chat Group Talk, a user joins an existing chat group. Existing, in this context, means that a unique identifier has 
been previously allocated for the chat group. Thus, both Chat Group Talks and Instant Group Talks have previously 
existing identifiers. The difference is that in an Instant Group Talk, when the first user joins the group, all the members 
of that Instant Group Talk are invited by the PoC Server. In a Chat Group Talk, when a user joins the group, no other 
user is implicitly invited. 
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8.9 Instant Personal Alert 

An Instant Personal Alert is a request from user A to user B for user B to establishes an Instant Personal Talk with user 
A. Instant Personal Alerts are similar to a call back service in the world of traditional telephony. They are implemented 
using the SIP MESSAGE method. User A is informed of the delivery result of the instant personal alert. 
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ANNEX A (informative): Known 3GPP/OMA divergence 

PoC industry specification phase 1 is based on 3GPP and IETF standards where feasible. In order to overcome 
limitations of the existing technology, the PoC phase 1 specifications contain some deviations from the 3GPP standards. 
Careful evaluation of these deviations is required in subsequent releases of Push-to-talk specification. These 
divergences included in the industry specification do not imply requirements on the 3GPP/OMA standards but the 
OMA standards work should follow and be aligned with the 3GPP IMS specifications as much as possible. 

This annex captures the known divergences from the 3GPP specification. 

• IP version 

The PoC phase 1 specification supports IPv4 only 

• Authentication and integrity protection 

The PoC phase 1 specification supports HTTP digest in place of the IMS-AKA specified by 3GPP. 

• Policy control 

The PoC phase 1 specification does not provide for the support of the IMS headers, related to the policy control 
(Go interface). 

• CSCF discovery 

The PoC phase 1 specifications describe the parameters which are required to be configured - this includes the 
contact address of the SIP proxy which the terrninal will communicate with. 

• Provisioning of private user ED 

The PoC phase 1 specifications describes the parameters which are required to be configured - this includes the 
private user identifier. In 3GPP this is located on the ISIM or derived from the USIM. 

• Floor control 

The PoC phase 1 specifications describes floor control. There is no suitable floor control standardized within 
the industry. 

• Group List Management 

The PoC phase 1 specifications describes a group list management protocol. The group list management work 
in 3GPP is still ongoing. 

• PoC header extension 

The PoC phase 1 specifications describes header extensions for identifying that the signaling is related to the 
PoC service, 

• Initial-. Re- & De-registration procedures 

The PoC phase 1 specifications do not use all the 3GPP specified SIP header fields and parameters and 
additionally the PoC phase 1 specifications use PoC specific header fields and parameters. 

• Reject and Error Codes in Sessions 

The PoC phase 1 specifications have specific usage of reject and error codes. 

• Conferencing 

The overall POC functionality has similarities with currently ongoing 3 GPP Rel6 conferencing work: Further 
alignments of these two activities are needed. 

• Group Identities 

The PoC phase 1 specification defines a mechanism for creating group identities. 3GPP has not yet completed 
the work on group management including handling of group identities and the Ut reference point. 

• Implicit subscription to refer state event 

The PoC phase 1 specifications establish with SIP INVITE method an implicit subscription which is not 
specified in 3GPP nor IETF. 
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